This invention relates to a method of analyzing an application and, more particularly, to a method of identifying the contributing factor for an invalid operation of a program in a 3-tier architecture Web application.
As a method of implementing an application in a Web system, 3-tier architecture is widely popular which configures an application from three layers: a Web layer, a logic layer, and a database layer. In 3-tier architecture, a service is realized as a serial combination of user interface presentation, an action in response to an input, and data operation corresponding to the action. Various Web systems are configured generally by combining a plurality of such services.
The increase in program scale and intricacy in recent years is making programs of the logic layer out of the 3-tier architecture complicate. On the other hand, there are many cases where the specifications of a program do not match the actuality of the software and cases where program specifications are not created in the first place due to frequent changes to specifications, man-hour reduction, hurried development/maintenance, and other reasons. This results in a situation where debugging and maintenance in program development take longer time.
A conventional way to avoid this situation is to understand the specifications of a program based on source code of the program and create a revision plan founded on the specifics thereof. The understanding of program specifications has been assisted with the use of such measures as a source code analysis tool which outputs a call relation (call graph) of steps in a program based on a static analysis result of the program, a program tracing tool which outputs a dynamic call relation of steps, and interactive execution trace of a program by a source-level debugger (See Non Patent Literature 1).
Generally speaking, a malfunction of a program is manifested as an error in control flow caused by erroneous control logic in the program, or data value invalidity caused by erroneous calculation logic in the program. The former can be verified by going over the control flow of the program with a source code analysis tool or a program tracing tool and checking whether or not actual operation is consistent with expected operation. The latter can be verified by stopping the execution of the program with a source code debugger at each execution point in time, and checking the value of a variable or the like.
In a service realized by the 3-tier architecture, program source code of the logic layer can be checked interactively by using a source-level debugger. Processing of a database layer program, on the other hand, can be carried out generally by issuing a command written in SQL, which is a database processing language, from a logic layer application to a database layer application.
The SQL command issued by the logic layer application is treated as string data and constructed dynamically in the logic layer program. The operation of the logic layer can therefore be checked by understanding what SQL statement is executed as the logic layer program is executed as well as the process of execution of the logic layer program, and using program tracing or an interactive debugger in combination. The overall operation of the programs of the 3-tier architecture can thus be checked.
Beside this method of detecting malfunction of a program by understanding the operation of the program, there is a method of detecting the vulnerability of a program via a static analysis of the program (see Non Patent Literature 2). Non Patent Literature 2 discloses a method using a data flow analysis approach to verify whether or not there is a data flow to an API that could give rise to a security problem, such as reference to a database from user input data or other types of low-reliability data. This method estimates that there is security vulnerability when a step that guarantees security is not found at some point in the data flow. According to this method, a problem of a program can be detected in a short time without needing the trouble of understanding program specifications in detail.
There is also a technology with which a module that verifies security vulnerability in this manner can be applied to a plurality of programming languages (see Patent Literature 1). Patent Literature 1 discloses means for providing a versatile security analysis module which is targeted for a plurality of programming languages including Java and PL/SQL. This technology once converts a plurality of programming languages into a uniform internal expression and applies analysis processing to the internal expression obtained by the conversion, thus realizing a versatile security analysis module.
Patent Literature 1 JP 2008-502046 A
Non Patent Literature 1 M. Linton. The Evolution of Dbx, In Proceedings of the 1990 Summer USENIX Conference, 1990.
Non Patent Literature 2 V. Livshits, et al., Finding Security Vulnerabilities in Java Applications with Static Analysis, In Proceedings of the 14th Conference on USENIX Security Symposium, 2005.
Non Patent Literature 3 Aho et al., Compilers: Principles, Techniques, & Tools, second edition, Addison-Wesley, 2006.